John LaCour writes: > > > [The hobbit sez...] > > >This brought to mind the idea of a "syslog monitor", or a process that would > >just hang out someplace and stat the various log files periodically, > >using some mechanism to warn of excessive size, mysterious shrinkage, and > >maybe some other warning signs. > > While you're at it, lets write a program to monitor the syslog monitor. In case > any one kills it, sends it signals, its pid changes, etc. > > Another idea is to find out how the intruders are getting in (or getting root) > and plugging those holes. Perhaps I'm missing something, but isn't this the point? Or, maybe my concerns are different since I'm at a University. Anyway, if someone does break in then wouldn't log files provide you with clues as to how and when? Armed with this info you could then work at plugging the holes. So, the question is, what's the best way to safeguard these log files? A secure log host, filter log messages based on space left on disk, forward interesting messages (what ever this may be) someplace else like to a printer, filter based on who (host, program) sent the log message. The goal would be to both get rid of nonsense messages generated by an attacker, and safeguard the real messages that show his/her activities. > If you're really concerned about intruders messing with your files, use tripwire > or something like that. Of course, tripwire may not be ideal for dynamic files > like pacct and lastlog, but alas your binaries are more important than your > logs. Yes, binaries should be monitored by tripwire ... I also agree that tripwire is not the best tool for monitoring logfiles. You would have to have tripwire check it quite often (checking for monotonically increasing) to have any sort of confidence in the results. fred --